home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / src / Tools / vtcl / doc / Interp.3 < prev    next >
Encoding:
Text File  |  1995-07-10  |  6.5 KB  |  140 lines
  1. '\"
  2. '\" Copyright (c) 1989-1993 The Regents of the University of California.
  3. '\" All rights reserved.
  4. '\"
  5. '\" Permission is hereby granted, without written agreement and without
  6. '\" license or royalty fees, to use, copy, modify, and distribute this
  7. '\" documentation for any purpose, provided that the above copyright
  8. '\" notice and the following two paragraphs appear in all copies.
  9. '\"
  10. '\" IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY
  11. '\" FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
  12. '\" ARISING OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF THE UNIVERSITY OF
  13. '\" CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  14. '\"
  15. '\" THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
  16. '\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
  17. '\" AND FITNESS FOR A PARTICULAR PURPOSE.  THE SOFTWARE PROVIDED HEREUNDER IS
  18. '\" ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO
  19. '\" PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
  20. '\" 
  21. '\" $Header: /user6/ouster/tcl/man/RCS/Interp.3,v 1.10 93/04/01 09:25:32 ouster Exp $ SPRITE (Berkeley)
  22. '\" 
  23. '\"----------------------------------------------------------------------------
  24. '\"    @(#) Interp.3 26.1 93/10/22 SCOINC
  25. '\"
  26. '\"     Copyright (C) The Santa Cruz Operation, 1992-1993.
  27. '\"     This Module contains Proprietary Information of
  28. '\"    The Santa Cruz Operation, and should be treated as Confidential.
  29. '\"----------------------------------------------------------------------------
  30. .so ../man.macros
  31. .HS Tcl_Interp tclc
  32. .BS
  33. .SH NAME
  34. Tcl_Interp \- client-visible fields of interpreter structures
  35. .SH SYNOPSIS
  36. .nf
  37. \fB#include <tcl.h>\fR
  38. .sp
  39. typedef struct {
  40.     char *\fIresult\fR;
  41.     Tcl_FreeProc *\fIfreeProc\fR;
  42.     int \fIerrorLine\fR;
  43. } Tcl_Interp;
  44.  
  45. typedef void Tcl_FreeProc(char *\fIblockPtr\fR);
  46. .BE
  47.  
  48. .SH DESCRIPTION
  49. .PP
  50. The \fBTcl_CreateInterp\fR procedure returns a pointer to a Tcl_Interp
  51. structure.  This pointer is then passed into other Tcl procedures
  52. to process commands in the interpreter and perform other operations
  53. on the interpreter.  Interpreter structures contain many many fields
  54. that are used by Tcl, but only three that may be accessed by
  55. clients:  \fIresult\fR, \fIfreeProc\fR, and \fIerrorLine\fR.
  56. .PP
  57. The \fIresult\fR and \fIfreeProc\fR fields are used to return
  58. results or error messages from commands.
  59. This information is returned by command procedures back to \fBTcl_Eval\fR,
  60. and by \fBTcl_Eval\fR back to its callers.
  61. The \fIresult\fR field points to the string that represents the
  62. result or error message, and the \fIfreeProc\fR field tells how
  63. to dispose of the storage for the string when it isn't needed anymore.
  64. The easiest way for command procedures to manipulate these
  65. fields is to call procedures like \fBTcl_SetResult\fR
  66. or \fBTcl_AppendResult\fR;  they
  67. will hide all the details of managing the fields.
  68. The description below is for those procedures that manipulate the
  69. fields directly.
  70. .PP
  71. Whenever a command procedure returns, it must ensure
  72. that the \fIresult\fR field of its interpreter points to the string
  73. being returned by the command.
  74. The \fIresult\fR field must always point to a valid string.
  75. If a command wishes to return no result then \fIinterp->result\fR
  76. should point to an empty string.
  77. Normally, results are assumed to be statically allocated,
  78. which means that the contents will not change before the next time
  79. \fBTcl_Eval\fR is called or some other command procedure is invoked.
  80. In this case, the \fIfreeProc\fR field must be zero.
  81. Alternatively, a command procedure may dynamically
  82. allocate its return value (e.g. using \fBmalloc\fR)
  83. and store a pointer to it in \fIinterp->result\fR.
  84. In this case, the command procedure must also set \fIinterp->freeProc\fR
  85. to the address of a procedure that can free the value (usually \fBfree\fR).
  86. If \fIinterp->freeProc\fR is non-zero, then Tcl will call \fIfreeProc\fR
  87. to free the space pointed to by \fIinterp->result\fR before it
  88. invokes the next command.
  89. If a client procedure overwrites \fIinterp->result\fR when
  90. \fIinterp->freeProc\fR is non-zero, then it is responsible for calling
  91. \fIfreeProc\fR to free the old \fIinterp->result\fR (the \fBTcl_FreeResult\fR
  92. macro should be used for this purpose).
  93. .PP
  94. \fIFreeProc\fR should have arguments and result that match the
  95. \fBTcl_FreeProc\fR declaration above:  it receives a single
  96. argument which is a pointer to the result value to free.
  97. In most applications \fBfree\fR is the only non-zero value ever
  98. used for \fIfreeProc\fR.
  99. However, an application may store a different procedure address
  100. in \fIfreeProc\fR in order to use an alternate memory allocator
  101. or in order to do other cleanup when the result memory is freed.
  102. .PP
  103. As part of processing each command, \fBTcl_Eval\fR initializes
  104. \fIinterp->result\fR
  105. and \fIinterp->freeProc\fR just before calling the command procedure for
  106. the command.  The \fIfreeProc\fR field will be initialized to zero,
  107. and \fIinterp->result\fR will point to an empty string.  Commands that
  108. do not return any value can simply leave the fields alone.
  109. Furthermore, the empty string pointed to by \fIresult\fR is actually
  110. part of an array of \fBTCL_RESULT_SIZE\fR characters (approximately 200).
  111. If a command wishes to return a short string, it can simply copy
  112. it to the area pointed to by \fIinterp->result\fR.  Or, it can use
  113. the sprintf procedure to generate a short result string at the location
  114. pointed to by \fIinterp->result\fR.
  115. .PP
  116. It is a general convention in Tcl-based applications that the result
  117. of an interpreter is normally in the initialized state described
  118. in the previous paragraph.
  119. Procedures that manipulate an interpreter's result (e.g. by
  120. returning an error) will generally assume that the result
  121. has been initialized when the procedure is called.
  122. If such a procedure is to be called after the result has been
  123. changed, then \fBTcl_ResetResult\fR should be called first to
  124. reset the result to its initialized state.
  125. .PP
  126. The \fIerrorLine\fR
  127. field is valid only after \fBTcl_Eval\fR returns
  128. a \fBTCL_ERROR\fR return code.  In this situation the \fIerrorLine\fR
  129. field identifies the line number of the command being executed when
  130. the error occurred.  The line numbers are relative to the command
  131. being executed:  1 means the first line of the command passed to
  132. \fBTcl_Eval\fR, 2 means the second line, and so on.
  133. The \fIerrorLine\fR field is typically used in conjunction with
  134. \fBTcl_AddErrorInfo\fR to report information about where an error
  135. occurred.
  136. \fIErrorLine\fR should not normally be modified except by \fBTcl_Eval\fR.
  137.  
  138. .SH KEYWORDS
  139. free, initialized, interpreter, malloc, result
  140.